If you still run PHP 7.x on CentOS 7, the PHP2Shell fix did not come for you. PHP shipped releases for 8.2 to 8.5 only. For people who cannot migrate overnight I rebuilt the one mitigation that exists for 7.4, and I am publishing the packages and the exact steps.

Short version: the right fix is moving to a supported OS and a supported PHP. These RPMs are a stopgap for the time it takes you to do that. They are unofficial, they come with no warranty, and you should be able to verify or rebuild everything yourself.

What happened

On 21 October 2026 the PHP project published an advisory for two critical flaws in PHP core, CVE-2026-109618 (out-of-memory handling that leaves request data half-built) and CVE-2026-109619 (stale global state). Both are rated 9.2 (CVSS v4.0) and can lead to remote code execution. Fixed releases are 8.5.12, 8.4.27, 8.3.36 and 8.2.35.

Reports differ on whether the flaws are already being exploited in the wild: watchTowr says yes, the advisory itself does not say so. I would not wait to find out.

Why CentOS 7 and PHP 7 users are stuck

• PHP 8.1 and older get no official update. For 7.4, 8.0 and 8.1 the security team published minimal source backports instead, as commits, not releases. The 7.4 one is 712e60f (“Minimal mitigation for EOL version”).
• Remi Collet’s php-7.4.33-31 source RPM includes that backport, but his EL7 repositories were closed on 2026-08-12, and the last EL7 binary is 7.4.33-15, without the fix.
• The advisory is blunt that mitigations reduce exposure and that updating is the only complete fix.

What I built

I rebuilt Remi’s php-7.4.33-31 source RPM on CentOS 7.9 with two small changes, both only so it compiles on EL7:

1. The spec asked for ICU 74 or newer. The newest ICU for EL7 is 73.2, so I relaxed the requirement to 73.
2. A version test in the ICU patch is quoted by mistake, so it is always true and forces C++17, which the EL7 compiler (GCC 4.8.5) cannot do. I removed the quotes so ICU 73 uses the C++11 path it was meant to.

Patches 242 and 243 (the mitigation itself) are untouched. I compared Patch 243 with the upstream 7.4 commit: same 17 files, and the added lines match, apart from ten lines about max_multipart_body_parts that the earlier Patch 242 already provides.

Everything is in the repo: github.com/exception0x876/php74-el7-patched: the two diffs, a rebuild script, the SRPM and the RPMs as release assets.

What it changes for your applications

The upstream mitigation has side effects you should know before installing:

• Session upload progress is switched off completely, whatever your php.ini says.
• Out-of-memory fatals go to stderr and exit immediately, not through the normal error handling and logging.
• The test suite runs during the build: 9,158 passed and 9 failed. The 9 failures are 8 upload-progress tests and one out-of-memory message test, all caused by the two changes above.

What I tested, and what I did not

I installed the packages in a clean CentOS 7 container (php -v, php -m, PHP-FPM serving a request, intl, gd, mbstring). I did not test exploitability, the packages have had no third-party audit, and you should test them with your own application before relying on them.

Verify before you trust

My signing key is VPS Gems RPM signing, fingerprint:

CA09 8610 7910 D598 A3EF  28DB EFCF D009 B413 7B36

gpg --import PUBLIC-KEY.asc
gpg --fingerprint CA0986107910D598A3EF28DBEFCFD009B4137B36
gpg --verify SHA256SUMS.asc SHA256SUMS
sha256sum -c SHA256SUMS --ignore-missing

The individual RPMs are not signed; trust comes from the signed SHA256SUMS. Better still, rebuild: ./build/build.sh in the repo downloads Remi’s SRPM, checks its hash, verifies its signature against Remi’s 2026 key (fingerprint 2E37 5FE2 4EDF F0F2 E0D8 E165 ED5B 58C5 BEFA 00E2, published by Remi), applies the two patches and builds in a clean container.

Installing, in outline

Take a full backup and decide on your rollback first. This replaces PHP, so do it in a maintenance window.

1. Download the RPMs for the subpackages you already have (rpm -qa 'php-*'), plus php-sodium, and verify them. The base php and php-common packages require php-sodium of the same version, which pulls in libsodium from EPEL.
2. Extensions built for PHP 7.3 will not load on 7.4. Replace PECL packages with their 7.4 builds. php-gd needs gd3php, php-mbstring needs oniguruma5php and php-intl needs libicu73, all from Remi’s [remi] repo.
3. Stop PHP-FPM first. The php-fpm RPM restarts the service on upgrade, and it will fail to start if php.ini still points at old extension files.
4. Install: yum localinstall <your downloaded rpms>.
5. If you use ionCube: you need the loader built for 7.4 from ionCube (I do not redistribute it). It must be the first zend_extension in php.ini, before OPcache, or PHP refuses to start.
6. Run php -v, php -m and php-fpm -t before you start the service, then start PHP-FPM and check the error logs.
7. Disable the old PHP repos so a routine yum update cannot swap PHP back.

To roll back: stop PHP-FPM, remove the 7.4-only packages (php-sodium, the 7.4 PECL builds), downgrade the rest to your previous RPMs, restore your old php.ini, start PHP-FPM. Keep the old RPMs on disk before you begin.

The real fix

Plan the move to a supported distribution and PHP 8.2 or newer (PHP 8.2 itself reaches end of life on 31 December 2026), and check that your application supports it. Once you are there, delete these packages and forget about them.

If you find a problem with the packages, open an issue on the GitHub repo.